The invention pertains to communications systems. More particularly, the invention pertains to communications systems wherein electrical devices in a respective system can be configured to operate with a subset of preloaded software. Additionally, the invention pertains to such systems wherein additional programs or data can be transferred between system devices in protected or encrypted form and wherein the respective device is able to assess the integrity of the received information.
Communication systems which incorporate a plurality of substantially independently operating processors are known. One form of such systems is represented by those which are dedicated to monitoring or supervising predetermined regions.
One such communication system is disclosed in Tice et al U.S. Pat. No. 4,916,432 entitled Smoke and Fire Detection System Communication. Another is disclose in Tice U.S. Pat. No. 5,525,962 entitled Communication System and Method. Both of the noted patents are assigned to the assignee hereof and are hereby incorporated herein by reference.
While known systems are useful and have been effective, it would be desirable to more readily configure the functional structure of respective processors to carry out one or more predetermined functions utilizing a common software base. It would also be desirable to be able to provide for secure transmission of information, including programs, between processors and to be able to verify that received files or programs exhibit a predetermined level of integrity.
In accordance with the present invention, processors in electrical devices which are a part of a multiple processor communication system can be loaded with a variety of executable programs or data files during the manufacturing or installation cycle. At some point during the manufacturing process or at installation, one or more identifiers can be provided to each respective device.
The identifiers can, for example, be stored in non-volatile memory such as EEPROM. The identifiers link together in some fashion, determined at either the manufacturing or installation time, a plurality of the prestored executable programs and perhaps related data files which are included in a universe of programs and data files commonly loaded into the non-volatile memories, such as ROM or EEPROM memories of the respective processors.
In one aspect, the identifiers can be loaded into the device after the device has been coupled to the communications system. In such an instance, the identifier or identifiers can be transmitted from another processor in the system. Alternately, an off-line programming unit can be used to provide the necessary identifier or identifiers to the respective device. The identifier or identifiers enable the respective device to select an appropriate subset of executable programs and/or data files to be used to carry out a predetermined function.
An advantage of the above-described system and method is that during the manufacturing phase, only one type of electrical device need be manufactured to satisfy the requirements of a wide variety of installations. In one aspect, and without limitation, some of the devices can include an ambient condition sensor. Different marketable products can be created by providing different identifiers, which select among the available executable code and available data files, to provide a specific predetermined function using the same hardware.
In yet another aspect, executable code and data files can be received from another processor or processors over an associated wired or wireless communications link in the system. The received information can be transmitted in encrypted form for purposes of providing a higher degree of security.
The received information can be decrypted by the receiving processor. Subsequent to decryption, the structure and information associated with the transmission can be evaluated to insure that it exhibits a predetermined integrity level before being incorporated into the device""s universe of executable programs and/or data files.
In another aspect, each device can be preprogrammed with multiple executable routines stored in non-volatile memory. The routines can be combined in various ways in order to form an over-all executable program to carry out a predetermined function. Those routines from the device""s universe which are to be combined for purposes of a particular device can be specified by an identifier which links each of the desired routines to at least one other routine of a particular subset.
In another aspect, an additional level of security can be provided. A predetermined password can be stored in each of the devices associated with a particular communications system. A system password can be transmitted along with other information as part of a transmitted message.
The received system password can be compared to the prestored password at each respective device. The received communication can be responded to if the passwords match in some sense. For example, if the received communication is an executable program to be added to a respective device""s universe of programs, it can then be stored in non-volatile memory.
If the passwords do not match, audible, or visible indications can be generated so that the mismatch will be addressed. For example, for those communication systems that include some form of a common operator control panel, messages can be produced at the control panel indicating that a particular device has found a mismatch between a transmitted system password and the device""s prestored password.
In another aspect, a transmitting device can encrypt a message prior to transmission to increase message security. A receiving device then decrypts the received message prior to evaluating message integrity.
In yet another aspect, a method using codes embedded in the messages can be used to xe2x80x9cbindxe2x80x9d devices to a specific control unit in a fire alarm, security, or control system. The binding process will prevent potentially inappropriate devices designed for one system from being used in another system without taking into account different hardware and software designed for each system.
In one form, the binding code includes a KEY code, which can be provided to designate a system designer. In addition, a SITE code can be downloaded into the devices for each specific installation.
The KEY can be used to synchronize the device in looking for the SITE code according to a predetermined routine which also may be unique for the system designer. The SITE code is further encrypted with random numbers to make detection and breaking of the code more difficult.
The KEY and SITE codes are stored in protected areas of a device""s processor. The SITE code can only be changed by using the old SITE code in combination with the new SITE code. The method of using KEY and SITE codes is also protected and cannot be xe2x80x9creadxe2x80x9d from the device""s processor.
To further make it more difficult to break the codes, they can be embedded in random numbers in a system that generates excessive non-relative numbers and the KEY only occurs randomly. This is an effective process where it is not necessary to establish the correct binding immediately in the system and with every message transmitted.
The operation of the system will require that a specific message be transmitted routinely. This message will contain the numbers in which the codes are embedded.
The devices will power-up and run until a respective device determines that its binding relationship with the control unit is not correct. The device assumes that it has the correct binding until the incorrect binding is detected in the device.
Once the incorrect binding is detected in the device, it can be verified in the next binding check. If the verification confirms that the binding codes are not correct, the device will transmit appropriate mismatch signals or messages to the control unit.
The mismatch state can be reset by a hard reset of the device (i.e. removal and re-insertion or removing power from the line). This will also reset other functions and signal processing algorithms running in the device.
If devices with the incorrect binding codes are connected to a control unit, the time until the mismatch message is generated will be a random time. Therefore, the mismatch indication will provide little information as to the location of the KEY and SITE codes.
In yet another aspect; it may be advantageous to also run a binding confirmation program by a command to the control unit. This can be done in a binding stage during the installation to insure that the proper devices are used with the control unit.
A BIND# code can be downloaded to the devices. The operator then selects the xe2x80x9cbindingxe2x80x9d routine which is then executed. A special message can be used that contains the random number with encrypted numbers. This message can run for a predetermined period of time (i.e. 200 messages) during the xe2x80x9cbindingxe2x80x9d process.
During this time, the control unit insures that the KEY# is transmitted a predetermined number of times (*i.e. 2 times for 200 samples because it falls within the proper probabilities or some number less than the highest random number and higher than the least other random number). The idea is to maintain the randomness of the system.
The devices will expect the KEY# to be received a predetermined quantity of times during the predetermined time period of the binding process. The control unit could alter the random numbers to fill in gaps to try to make the histogram of random number values flat.
At the end of the binding process, any failures will be immediately communicated to the control unit.
In order that the binding of a system cannot be simply copied and used with other control units, the system can continue to run with the encryption method. Later the devices will go into a mismatch state if they mismatch the KEY# and BIND# encrypted codes. A binding process initiated by a command to a selected unit can use a different KEY# than the continual running program. This will further prevent copying of the series of numbers generated by the panel command and then just repeating them during the continual running program.
Message integrity can be checked in accordance with the present invention using a wide range of methodologies. For example, a locally generated check sum of a received decrypted message can be compared to a transmitted check sum generated at the transmitting device. Alternately, an address of a memory location at the receiving device and the expected contents of that address can be transmitted in encrypted form to the receiving device. After decrypting the communication the received contents of the indicated address to the actual contents of the same address can be compared at the receiving device to establish the integrity of the received information.
In yet another aspect, the method can be used to verify downloaded information or to verify that a program is functioning properly. It is possible that a data file can be run through device based signal processing programs and the output compared to an expected value after each data sample. If the data samples match, then the program configuration is unchanged. The check program can also verify that downloaded information is correct.
In one embodiment, the method of verification involves transmitting a register or storage location along with a value. The device will compare the contents of the register location to the value transmitted. If they match, then the device will respond with a transmission indicating that there has been a match. Any register can then be checked at any time to verify that the device is functioning properly.
All comparisons are made in the device. Therefore, the device does not have to send values to the transmitting unit or programmer prior to comparing the expected value to the actual value.
The transmitting unit or programmer can use the verify or check method with groups of devices at the same time. The groups can be formed by location by application or by type of device.
The devices with the matches between their stored value and the predetermined value would respond individually. This response could be in a special message that has a specific time slot for each device to give its response it.
An exemplary process includes:
1. Sending a command to the device to perform a test of a module that executes a signal processing algorithm using values in a data file. The transmitting unit or a programmer can be used to transmit the commands and data values.
2. The first data value is transmitted to the device and the device initializes all values for this test based upon the data value transmitted. Current running values in RAM are being transferred to EEPROM so they are not lost because of carrying out this test.
3. The second data value is transmitted to the device and the device processes that value.
4. The verify message is sent to compare the output of the device processor (in a specific register address) to a value previously determined and included in the message. If the output of the device processor matches this value, a signal is sent to the transmitting unit or programmer that it matches.
5. Another data value is transmitted to the device and the device processes that value.
6. The verify message is sent to compare the output of the device processor (in a specific register address) to a value previously determined and included in the message. If the output of the device processor matches this value, a signal is sent to the control unit or programmer that it matches.
7. #5 and #6 repeat until all data values have been sent. After the data file is complete, if all processed output values are the same as the previously determined values, then the instructions of the tested module exhibit an expected degree of integrity.
8. A command can then be sent to the device to restore to normal operation. The stored running values, which previously transferred to EEPROM, are now transferred back to RAM and the device continues running from the point it was at just before the test was conducted.
The verify message does not have to be sent after every data sample. For example, it may only be sent when a certain predetermined processed output value is expected, such as reaching a pre-alarm or alarm threshold.
Where the electrical unit is an ambient condition detector, this method can be used to verify that algorithms or processing programs stored therein which may have been modified still comply with agency requirements. Standard data files representing sensor response to test fires used for approval or listing can be used.
An alternate process can be used to check the integrity of files stored in ROM, EEPROM or read/write memory. Steps include:
1. Sending a command to a device or devices to determine if the contents of a specific storage or register address in the device matches a predetermined value which is included in the message to the device. If the storage or register value matches the predetermined value, a signal is sent to the transmitting unit or programmer.
2. Step 1 is repeated for all RAM, ROM, or EEPROM storage or register locations that are to be checked.
An alternate process can be used to verify the status of a processor in a device. Steps include:
1. Sending a command to a device or devices to check a specific register address in the device with an AND function to see if any bits in that register match the bits in the predetermined value. Each bit location corresponds to a specific state. Alternately, a separate register location can be used for each state.
2. Step 1 is repeated for all state conditions that are to be checked.
It will be understood that device based software usable to carry out the above described types of integrity tests can be stored in EEPROM. The exact coding used to implement one or more integrity tests is not a limitation of the present invention.
Numerous other advantages and features of the present invention will become readily apparent from the following detailed description of the invention and the embodiments thereof, from the claims and from the accompanying drawings.